1. Technical Field of the Invention
The present invention relates generally to a method for policy-based control of a communication network having a distributed architecture, including at least one heterogeneous communication.
2. Description of Related Art
In an open services market, network operators will have to provide highly secure, open, standard interfaces to their networks.
Policy-based control of a network is a recent approach to meet these requirements by distribution of functionality among network components and simplifying linking the distributed functionality to one another by employing policies. Policies are statements that dictate what policy enforcements and behaviours are permitted and on which events (hereinafter called Events) in a computer- or telecommunications network. A network administrator may define a set of policies governing the network.
According to the state of the art there are methods and systems developed for policy enforcement and policy management. Policy management and policy evaluation is e.g. currently drafted by a Parlay Policy Management Working Group of the Parlay Group, which is a multi-vendor consortium formed to enable the development of applications that operate across multiple, networking-platform environments by developing open, technology-independent application programming interfaces (APIs). The Parlay Policy Management Working Group (PPMWG) is set up to maintain and enhance the Parlay Policy Management and -Evaluation APIs that enable management of policy domains within the network which domains are firstly independent of network architectures and secondly independent of transport/application protocols. The draft of the PPMWG on policy management covers the composition of policies and the latest contributions also describe policy evaluation.
One example of policies being applied is that currently, networks may provide different services to clients by employing the aforementioned policy management methods. These networks rely on traffic handling mechanisms of the network elements that are transferring data. These elements are mostly switches, routers, proxies and protocol gateways. Such protocol gateways have for instance been defined in Parlay. Also examples of these elements are “Common Service Enablers” and “Other Service Enablers” as defined by OMA. An enabler (Enabler), in this context, is a logical entity that offers certain services. Its services may typically be invoked by means of an interface.
The traffic handling mechanisms include mechanisms that determine to which flow traffic belongs, and queuing mechanisms by which resources may be assigned to a particular flow. Network elements that support traffic handling mechanisms are also referred to as Policy Enforcement Points (PEPs) because they are able to apply policies to the traffic transferred by them.
In addition, network elements must support mechanisms by which their traffic handling functionality can be executed or configured. Typically, PEPs are associated with some form of Policy Server, also known as a Policy Decision Point (PDP). Typically, a PDP supports one or more commonly known configuration protocols, such as Common Open Policy Services (COPS), which is a protocol between a PEP and a PDP, where the PEP requests a decision from the PDP. For top-down provisioning, a PDP may use COPS-PR to push top-down configuration information to associated PEPs. COPS-PR is an extension to COPS where the PDP contacts a PEP.
Some PEPs may include PDP functionality locally. Others may invoke the PDP functionality from a separate Policy Server. In this way PEPs and PDPs work together to apply policies, acting on policy data related to e.g. business to business configuration, privacy, security and authorisation, that are typically stored in some form of register database (hereinafter called Register).
The described state of the art specifications consider the PEP a client and the PDP a server. An example of this approach is the aforementioned COPS protocol. The Internet Engineering Task Force (IETF) is further developing COPS. COPS may be applied in a client/server model for supporting policy control over quality of service signaling protocols, but may in general be applied to any other situation with distributed control. The policy framework illustrated in the COPS specification describes the entities PEP and PDP and the mechanism for the PEP to initiate a relation establishment with a PDP. It also describes messages for the interaction between the PEP and the PDP. The model is based on the server returning decisions to policy requests, wherein the PEP sends a request to the PDP to become its client and wherein the PDP as server decides whether or not to accept the PEP client.
Other models that refer to policy management are described in e.g. the Policy Core Information Model (RFC3060), which defines in Unified Modeling Language notation, the classes that a policy may be composed of (policy, policy rule, policy rule Event, policy rule Action); and Radius (RFC2138) and Diameter, which may be used to request decisions regarding network access.
Systems according to the current art comprise a PEP sending out a decision request to a PDP when a specific Event occurs at the entity implementing the PEP. The PEP sends information about the Event or a pointer to such information to the PDP. The PDP evaluates the Events against policy and decides the appropriate policy enforcement. Subsequently the PDP returns its decision on how the PEP must act on the Event to the PEP and the PEP carries out (enforces) the decision taken by the PDP.
Other standards like Radius do not cover the establishment of the Client/Server relationship or the PEP/PDP relationship or do not cover the exchange of Event notification and policy enforcement capabilities of the PEP. Event notification Capability in this context means the capability to notify Events that are occurring, such as a request for access to the network, a request for resource usage or a request for any other service. Policy enforcement capability in this context means modification by the PEP of such service request, (partial) refusal of such service request and/or performing other policy enforcements by the PEP that can be suggested by the PDP.
The current approach by systems, policy models, framework and standards, which considers the PEP a client of the PDP server has inherent limitations, and especially lack:                Possibility for Multiple Stakeholders (hereinafter called Stakeholders) such as operators, application developers, vendors, governmental organizations, end-users or service providers, to subscribe to PEP capabilities outside their service domain; and        An easy way for defining policies to be enforced by PEPs without having to first register the capabilities of the PEP.        